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1.  INTRODUCTION 

During  the  late  1970s,  engineers  and  information  scientists  saw  the  need  to  communicate  designs, 
in  the  form  of  engineering  drawings,  among  the  variety  of  computer-aided  drafting  (CAD)  systems  coming 
into  widespread  use  within  the  engineering  community.  Personnel  from  Boeing  and  General  Electric 
collaborated  on  a  scheme  to  make  it  possible  for  different  CAD  systems  to  exchange  data  without  resorting 
to  special  programs  to  translate  from  one  internal  database  to  all  the  other  possible  formats.1  The  scheme 
was  conceptually  simple:  define  a  file  format  that  all  systems  could  understand  (i.e.,  read  and  write).  Then 
when  two  different  CAD  systems  needed  to  exchange  data,  the  sender  would  produce  the  neutral  data  file 
for  the  receiver  to  read.  Out  of  this  early  work  evolved  the  Initial  Graphics  Exchange  Specification  (IGES), 
which  was  developed  by  am  all-volunteer  organization  including  representatives  from  industry,  government, 
and  academia.2  The  first  specification  was  completed  in  1980  and  became  an  American  National 
Standards  Institute  (ANSI)  standard  in  1981. 3  The  original  specification  dealt  mainly  with  the 
representation  of  two-dimensional  engineering  drawings,  but  did  include  some  capability  to  exchange  three- 
dimensional  curves  and  surfaces.  As  CAD  systems  evolved  from  purely  drafting  applications  to  computer- 
aided  drafting  and  design  (CADD)  functions,  then  to  today's  computer-aided  design  (CAD)  workstations  with 
solid  modeling  capabilities,  the  IGES  community  recognized  the  need  for  a  mechanism  to  exchange  solid 
models  as  well  as  flat  drawings.  The  IGES  4.0  specification,  completed  in  June  of  1988,  includes 
capabilities  to  represent  constructive  solid  geometry  models.4  This  version  of  IGES  became  an  ANSI 
standard  (ASME  Y14.26M-1989)  in  1989  and  is  entitled  "Digital  Representation  for  Communication  of 
Product  Definition  Data."5  ASME  Y14.26M-1989  is  the  current  standard  and  is  the  basis  for  the  work 
presented  in  this  report.  But  the  latest  version  of  IGES — Version  5.1— was  released  in  September  of  1991 
and  will  soon  begin  the  process  toward  becoming  an  ANSI  standard.  The  major  enhancement  in  IGES  5.1 
is  additional  capability  in  the  solid  modeling  area — namely,  support  for  boundary  representation  models.5 
When  this  IGES  version  becomes  a  standard,  the  capabilities  will  exist  for  virtually  complete  exchange  of 
solid  models  among  unlike  CAD  systems. 

2.  SOUD  MODELS 

Generally,  there  are  three  accepted  types  of  solid  modeling  techniques 

•  Constructive  Solid  Geometry  (CSG) 

•  Boundary  Representation  (BREP),  and 

•  Hybrids. 

The  CSG  system  uses  a  variety  of  (generally  simple)  primitive  solid  shapes,  such  as  cones,  cylinders, 
spheres,  ellipsoids,  boxes,  and  so  forth,  as  the  basis  for  the  construction  of  more  complex  objects  by 
employing  combining  operators  such  as  union,  intersection,  and  subtraction.  Often  the  combining  operators 
are  called  booleans.  Sometimes  the  familiar  combining  operations  are  hidden  from  the  user,  but  they  are 
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stilt  there  nevertheless.  For  example,  in  a  feature-based  CSG  system,  the  user  can  “drill"  a  hole  through 
an  object  by  specifying  a  hole  command,  rather  than  by  explicitly  defining  the  “hote”  as  a  subtraction  of 
the  appropriate  cylinder  from  the  object.  However,  the  subtraction  operator  and  the  operands  are  stored 
by  the  CSG  system  (as  a  form  of  boolean  tree)  to  define  the  new  object. 

The  BREP  systems  create  solid  objects  by  defining  a  surface  (or  a  collection  of  surfaces)  that 
completely  encloses  the  volume  of  the  object.  The  shape  of  the  surface(s)  defines  the  shape  of  the  object. 
These  surface  definitions  often  include  a  variety  of  forms  such  as  B-splines,  Bezier  patches,  Coons 
patches,  simple  planes,  or  merely  faceted  (tesseiated)  surfaces. 

Hybrid  systems  are  a  combination  of  both  CSG  and  BREP.  The  user,  typically,  can  choose  from 
a  palette  of  simple  shapes  and  then  use  combining  operations  to  produce  a  model;  or  the  user  may  select 
from  a  variety  of  surfaces  and  trim,  cut,  or  otherwise  manipulate  them  to  define  the  model.  However,  nearly 
all  hybrid  systems  evaluate  their  CSG  constructs  to  produce  a  final  BREP  form  of  the  model.  The  current 
release  of  the  Army  Research  Laboratory's  (ARL)  Computer-Aided  Design  package  (BRLCAD  4.0)  is  a 
hybrid  system,  although  its  CSG  capabilities  are  most  visible  and  available  to  the  user  in  the  interactive 
editor  mged,  and  BRLCAD  does  not  generally  produce  the  final  model  as  a  BREP.  The  spline-surfaced 
solid,  the  ARS  solid,  the  polysolid,  and  the  new  NMG  solid  are  all  examples  of  BREP-type  objects. 

As  designers  became  more  dependent  on  CAD  systems,  there  was  a  logical  progression  into  solid 
modeling  because  of  its  useful  potential.  Remember,  human  beings  invented  engineering  drawings  to 
capture  and  communicate  design  intent  among  humans.  But  now  humans  are  coming  to  realize  that 
machines  can  recognize  design  intent  more  easily  in  forms  other  than  three-view  engineering  drawings. 
Today’s  emphasis  is  on  machine-to-machine  communication,  often  linking  the  design  of  a  part  (on  one 
machine)  to  ultimately  the  computer-driven  machine  tool  (on  another  machine).  Thus,  the  solid  model  is 
emerging  as  the  specification  of  the  part  (the  product  definition).  Accordingly,  many  CAD  vendors  include 
solid  modeling  capabilities  in  their  systems  and  some  are  including  additional  applications  capabilities  such 
as  finite  element  analysis  based  on  the  solid  model.  (The  term  computer-aided  engineering  (CAE)  is 
evolving  as  the  descriptor  used  to  distinguish  the  workstation  with  these  new  capabilities  from  the  traditional 
CAD  faculty.)  As  the  engineers  in  the  1970s  realized  that  some  method  was  needed  for  exchanging  CAD¬ 
generated  engineering  drawings  between  CAD  systems,  now  they  realize  that  the  same  need  exists  for 
CAD-generated  solid  models. 
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3.  IGES 


One  might  ask  that  if  translators  between  CAD  system  A  and  B  were  required,  then  why  not 
produce  those  direct  translators  instead  of  using  the  neutral  file  format  scheme  of  IGES?  For  a  small 
number  of  CAD  systems  that  solution  may  be  reasonable,  but  consider  how  many  translators  would  be 
needed  for  exchange  between  a  large  number  of  systems.  For  each  and  every  pair  of  CAD  systems  two 
translators  are  required,  one  for  each  direction  (i.e.,  one  to  produce  the  data  file  and  another  to  read  the 
data  file).  The  number  of  translators  required  for  full  exchange  capability  among  a  group  of  n  CAD  systems 
is 

n  (n  •  1 ). 

The  number  of  translators  required  for  a  data  exchange  via  IGES  is  simply 

2n, 

because  every  CAD  system  requires  just  two  translators  (one  for  incoming  and  one  for  outgoing).  Note 
that  the  number  of  IGES  translators  required  for  the  IGES  scheme  increases  only  linearly  with  the  number 
of  CAD  systems,  while  the  number  required  for  direct  translation  increases  as  the  square  of  the  number 
of  CAD  systems. 

Nearly  every  CAD  system  on  the  market  today  supports  exchange  of  two-dimensional  drawings 
via  IGES.  An  example  of  a  drawing  received  at  ARL  in  IGES  format  is  shown  in  figure  I7.  Although  the 
IGES  form  of  that  drawing  has  no  direct  application  to  generating  a  solid  model  of  the  helicopter  in  the 
BRLCAD  system,  it  must  be  noted  that  the  IGES  file  does  contain  data  suitable  for  capture  by  a 
preprocessor  that  could  simplify  the  making  of  the  solid  model.  Work  is  in  progress  with  just  that  objective; 
however,  that  exploitation  of  IGES  is  beyond  the  scope  of  this  report. 

The  IGES  specification  defines  a  neutral  file  format  for  the  exchange  of  product  definition  data. 
This  neutral  file  may  be  in  one  of  three  formats:  ASCII,  compressed  ASCII,  or  binary.  The  ASCII  form  is 
the  most  commonly  used  and  is  the  only  form  considered  in  this  report.  This  format  is  based  on  fixed- 
length  80-character  records.  The  ASCII  file  format  consists  of  five  sections,  a  start  section,  a  global 
section,  a  directory  section,  a  parameter  section,  and  a  terminate  section.  Figure  2  shows  an  example  of 
an  ASCII  format  IGES  file. 


The  start  section  is  merely  a  place  for  any  human-readable  comments  that  the  sender  wishes  to 
include.  The  global  section  contains  information  for  use  by  the  post-processor  (receiving  translator)  such 
as  the  units  used  in  the  IGES  file,  a  scale  factor,  the  date  the  file  was  generated,  the  sender’s  name,  and 
so  forth.  The  actual  data  in  the  IGES  file  are  recorded  as  a  number  of  entities.  Each  entity  has  a  specific 
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purpose  and  a  specific  format  within  the  file.  Each  entity  must  have  its  own  entry  in  the  directory  section. 
Directory  section  entries  consist  of  two  80-character  records  that  contain  information  about  that  particular 
entity  such  as  what  type  of  entity  it  is,  whether  this  entity  requires  a  transformation  matrix  applied  to  it  (and 
where  the  directory  entry  for  the  matrix  can  be  found),  the  form  number  (if  required),  the  color  of  the  object, 
and  where  the  parameters  that  define  this  entity  are  located.  The  pointers  in  the  directory  section  that 
indicate  where  other  data  are  to  be  found  are  simply  sequence  numbers — literally,  line  numbers — usually 
in  the  parameter  section.  The  parameter  section  contains  the  detailed  data  for  each  entity  in  a  free-form 
style  with  each  field  separated  by  an  end-of-field  delimiter  and  each  record  terminated  with  an  end-of- 
record  delimiter.  Both  these  delimiters  are  defined  in  the  global  section.  The  parameter  section  is  followed 
by  the  terminate  section  which  consists  of  a  single  80-character  record  containing  the  number  of  records 
used  for  each  section  of  the  file. 
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IQES  supports  the  following  entities  for  a  CSG  solid  model 

1.  Block 

2.  Right  Angular  Wedge 

3.  Right  Circular  Cylinder 

4.  Right  Circular  Cone  Frustum 

5.  Sphere 

6.  Torus 

7.  Ellipsoid 

8.  Solid  of  Revolution 


ICES  file  generated  from  an  AutoSolid  aasanbly  by  the  S 

ICES  translator  f root  Autodesk  Inc.,  translator  version  XGES3.0  5 
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000000001D 
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11 
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Figure  2.  ASCII  80-Character  Record  Form  of  IGES  File 


9.  Solid  of  Linear  Extrusion 

10.  Solid  Instance 

11.  Boolean  Tree 

12.  Solid  Assembly 

The  first  seven  of  these  entity  types  are  simple  primitive  shapes,  and  the  directory  section  entry  for  each 
would  contain  a  pointer  to  a  parameter  section  entry  that  contains  data  such  as  vertices,  radii,  length 
vectors,  and  so  forth.  The  parameter  section  entry  for  the  solid  of  revolution  would  contain  a  pointer  to 
another  directory  entry  for  some  type  of  curve  definition  entity  as  well  as  a  point,  axis,  and  a  rotation  angle. 
The  curve  is  rotated  about  the  axis  through  the  rotation  angle  to  generate  (define)  the  solid.  The  solid  of 
linear  extrusion  specifies  a  closed  curve  (representing  the  cross  section  of  the  extrusion)  and  a  vector  to 
define  the  direction  and  distance  the  cross  section  is  to  be  extruded. 

Both  the  solid  of  revolution  and  the  solid  of  linear  extrusion  may  make  use  of  any  of  the  IGES  curve 
entities.  These  curves  may  be  specified  using  any  of  the  following  entity  types: 

1 .  Circular  Arc 

2.  Conic  Arc 

3.  Line 

4.  Copious  Data 

5.  Parametric  Spline 

6.  Rational  B-Spline 

7.  Composite  Curve 

The  first  three  of  these  are  obvious  curve  types.  The  copious  data  curve  is  merely  a  series  of  data  points 
to  be  connected  by  straight  lines.  The  splines  offer  two  types  of  smooth  curves,  and  the  composite  curve 
is  a  single  curve  with  a  series  of  segments  made  up  of  any  mix  of  the  above  curve  types  (including  more 
composite  curves). 

The  solid  instance  entity  allows  a  copy  of  another  solid  to  be  used  without  redefining  it  and  includes 
the  capability  to  apply  a  different  transformation  matrix  to  the  copy.  The  boolean  tree  entity  describes  the 
operations  and  operands  to  build  an  object  which  may  be  the  entire  model  under  consideration  or  just  a 
small  part.  The  operators  allowed  in  the  boolean  tree  are  intersection,  union,  and  subtraction.  The 
operands  may  be  any  CSG  solid,  solid  instances,  or  other  boolean  trees.  The  solid  assembly  entity  defines 
a  collection  of  items  that  share  a  fixed  geometric  relationship.  Any  solid  objects  may  be  grouped  by  this 
entity. 
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4.  IGES-TO-BRLCAD  APPROACH 

Most  of  the  CSG  entities  in  IGES  can  be  directly  converted  to  a  corresponding  object  in 
BRLCAD — however,  there  are  a  few  exceptions.  The  block  and  the  right  angular  wedges  convert  directly 
to  the  BRLCAD  genarb8  solid.  The  right  circular  cylinder  and  right  circular  cone  frustum  entities  convert 
directly  to  the  gentgc  solid;  the  sphere  and  ellipsoid  entities  convert  to  the  genell  solid;  and,  of  course,  the 
torus  entity  converts  directly  to  the  BRLCAD  tor  solid.  The  solid  instance  entity  is  implemented  by  simply 
creating  another  copy  of  the  instanced  solid  in  the  BRLCAD  model. 

The  solid  of  linear  extrusion — one  of  the  exceptions  noted  above — is  not  currently  a  supported 
primitive  in  BRLCAD,  so  we  approximate  it  by  using  a  combination  of  other  BRLCAD  primitives.  In  cases 
where  the  curve  to  be  extruded  is  simply  a  single  circular  or  conic  arc,  then  a  BRLCAD  gentgc  solid  is 
produced.  If  the  curve  to  be  extruded  is  anything  else,  we  approximate  the  curve  by  a  series  of  straight 
line  segments  and  a  BRLCAD  polysolid  is  built.  The  sides  are  all  polygons  of  four  vertices  and  the  top  and 
bottom  surfaces  are  simply  additional  polygons  to  close  the  ends. 

The  solid  of  revolution  is  also  implemented  by  approximating  the  defining  curve  as  a  series  of 
straight  line  segments.  When  the  approximating  curve  is  revolved,  each  straight  line  segment  generates 
a  BRLCAD  gentgc  solid.  This  “stack”  of  solids  is  then  combined  to  form  the  final  approximation  to  the 
IGES  entity.  Exactly  how  these  solids  are  combined  depends  on  the  form  number  of  the  IGES  solid.  The 
form  number  is  another  piece  of  data  that  is  included  in  the  directory  section  entry  for  each  entity.  For  a 
solid  of  revolution,  the  form  number  indicates 
whether  the  curve  to  be  revolved  is  closed  upon 
itself  or  is  closed  upon  the  axis  of  revolution.  If  the 
curve  is  closed  upon  the  axis  of  revolution,  then 
the  final  object  is  merely  the  union  of  all  the 
approximating  solids.  If  the  curve  is  closed  upon 
itself,  then  the  final  object  must  have  a  hollow 
section  through  the  center,  and  the  approximation 
must  be  built  with  the  appropriate  combination  of 
unions  and  subtractions  of  the  “stack"  of  solids. 

The  solid  assembly  entity  is  directly 
analogous  to  the  BRLCAD  group  and  is  converted 
directly  to  that  form.  The  boolean  tree  entity, 
however,  presented  some  difficulties.  IGES 
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defines  the  boolean  tree  in  a  postorder  notation  that  allows  for  easy  construction  of  a  binary  tree  in  memory 
through  the  use  of  a  stack  algorithm.  An  example  of  a  boolean  tree  is  shown  in  figure  3.  The  postorder 
notation  that  an  IQES  translator  would  produce  for  this  tree  is 

ABCUDDEnU. 

The  equivalent  infix  notation  for  this  tree  is 

(A  n  (B  U  C))  U  (D  n  E). 

Note  that  the  parentheses  are  required  for  correct  evaluation  of  this  tree. 

Since  BRLCAD  does  not  support 
postorder  notation  nor  permit  parenthetical 
expressions  in  region  definitions,  an  IQES 
boolean  tree  cannot  be  directly  converted  to 
a  BRLCAD  region,  in  general.  Because  of 
its  ancestry,  BRLCAD  has  inherited  the 
property  that  there  are  implied  parentheses 
at  the  union  operators,  i.e.,  all  the 
operations  between  the  union  operators  are 
performed  first,  then  the  unions  are 
evaluated.  These  facts  lead  to  some 
restrictions  on  the  form  of  the  boolean  trees 
that  may  be  directly  converted  to  BRLCAD 
regions.  These  restrictions  may  be 
summed  up  by  saying  that  no  union 
operator  may  appear  at  a  node  in  the  tree 
below  any  nonunion  operator.  In  general, 
any  boolean  tree  may  be  rewritten  to  satisfy 
that  requirement  by  applying  a  series  of 
transformations  to  its  subtrees.  An  example  of  just  such  a  transformation  is  shown  in  figure  4.  Here,  a 
subtree  of  the  previous  example  illustrates  a  situation  where  a  union  operator  appears  below  an 
intersection  operator.  This  subtree  is  easily  rewritten  (as  shown  in  the  figure)  to  move  the  union  operation 
up  the  tree.  When  this  subtree  L  Jaced  back  in  the  original  tree,  the  result  is  a  tree  that  conforms  tr  tha 
BRLCAD  syntax— while  still  producing  the  same  resultant  object.  Figure  5  illustrates  the  final  tree  structure, 
which  can  now  be  expressed  in  BRLCAD  syntax  as 

A  +  BuA  +  CuD  +  E, 


Figure  4.  Subtree  Transformation 
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where  +  is  the  intersection  operator  (D).  and  u  is  the  union  operator  (u).  This  region  is  then  constructed 
in  the  BRLCAD  model. 

A  series  of  transformations  was  developed  to  convert  from  IGES  postorder  notation  to  BRLCAD 
syntax  by  examining  all  possible  subtree  situations  where  a  union  operator  appears  below  a  nonunion 
operator  and  constructing  an  equivalent  tree  with  the  union  operator  at  the  top.  The  only  remaining 
difficulty  is  the  fact  that  IGES  allows  boolean  trees  to  reference  other  boolean  trees.  In  BRLCAD,  a  group 
may  reference  another  group,  but  a  region  referencing  another  region  is  generally  not  supported.  Since 
BRLCAD  groups  are  only  unions  of  a  collection  of  objects,  it  appears  that  after  having  solved  the  boolean 
tree  problem,  neither  the  BRLCAD  region  nor  the  BRLCAD  group  will  satisfy  our  requirements.  However, 
the  regions  and  groups  in  BRLCAD  are  really  just  varieties  of  the  same  type  of  object— called  a 
combination  in  BRLCAD— with  a  flag  in  the  structure  indicating  that  a  particular  object  is  a  region.  BRLCAD 
actually  supports  combinations  that  reference  other  combinations  as  long  as  the  combination  isn’t  flagged 
as  a  region.  So  the  resulting  boolean  trees  from  IGES  may  be  converted  to  BRLCAD  combinations. 

5.  CURRENT  STATUS 

An  IGES-to-BRLCAD  translator  (post-processor)  has  been  developed  based  on  the  ANSI  standard 
ASME  Y14.26M-1989,  which  is  essentially  IGES  4.0.  Therefore,  this  translator  accommodates  (with 
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approximations  in  some  cases)  all  the  ANSI  (i.e.,  IGES)  CSG  entities.  The  translator  does  not  support  the 
IGES  BREP  entities  from  IGES  Version  5.1  The  current  translator  reads  the  IGES  file,  checks  for  correct 
syntax,  then  proceeds  to  construct  the  BRLCAD  model.  The  translator  makes  extensive  use  of  the 
BRLCAD  libwdb  package,  thus  avoiding  concerns  about  the  details  of  the  BRLCAD  database  format  as  well 
as  future  concerns  about  changes  to  that  format  The  following  routines  from  libwdb  are  used: 

1.  mk_id — creates  an  idertt  record  for  the  entire  database 

2.  mkjrcc— creates  a  right-circular  cylinder 

3.  mk_trc — creates  a  truncated  right-circular  cone 

4.  mkjgc— creates  a  truncated  general  cone 

5.  mk_arb8 — creates  a  polyhedron  of  eight  vertices 

6.  mk_sph— creates  a  sphere 

7.  mk_ell — creates  a  general  ellipsoid 

8.  mktor — creates  a  torus 

9.  mk_addmember— adds  a  name  to  a  list  of  members  for  future  inclusion  in  a  group 

10.  mk  lcomb — creates  a  combination,  region,  or  group. 

When  transformation  matrices  and  translations  are  present  in  an  IGES  file,  they  follow  the  same  convention 
as  BRLCAD  does  and  can  be  used  as  arguments  in  the  mk_addmember  calls  for  building  combinations. 
Any  transformations  applied  to  top  level  objects  are  applied  by  creating  a  new  top  level  group  named  “all” 
that  contains  all  unreferenced  objects  with  their  transformations  applied. 


Figure  6.  Model  received  from  a  Calma  CAD  Figure  7.  Part  Model  used  for  AUTOFACT  V 
system  demonstration 
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The  IGES-to-BRLCAD  post-processor  described  above  has  been  implemented  and  has  been 
successfully  exercised  on  a  number  of  actual  IGES  CSG  files.  Some  of  these  files  were  obtained  from 
CAD  systems  that  support  IGES  and  some  were  hand  developed  for  the  purpose  of  testing  this  software. 
Figures  6  through  9  illustrate  solid  models  that  were  originally  generated  on  a  Caima  CAD  system  and 
translated  to  BRLCAD  via  IGES.'  The  models  were  converted  to  BRLCAD  using  the  IGES-to-BRLCAD 
translator  and  then  rendered  by  BRLCAD’s  ray-tracer  rt 

These  models  contained  some  of  the  IGES  entities  that  are  not  supported  by  BRLCAD.  However, 
the  resulting  models  are  certainly  acceptable  for  most  applications.  The  necked-down  cylinder  portion  of 
the  part  in  figure  6  is  a  solid  of  revolution  (and  approximated  by  a  combination  of  BRLCAD  gentgc 
primitives  as  described  above).  The  three  "ears”  on  the  same  part  are  solids  of  linear  extrusion  (and  are 
BRLCAD  polysolid  approximations).  Figures  7  and  8  show  two  views  of  a  model  that  was  used  as  the 
AUTOFACT  V  demonstration  part.  AUTOFACT  is  a  national  convention  focusing  on  manufacturing 
technology  and  the  transfer  of  part  designs  from  system  to  system.  The  model  in  Figure  9  contains  three 
solids  of  linear  extrusions  and  five  solids  of  revolution.  In  spite  of  our  translator’s  approximations,  we  think 
the  reader  will  agree  that  the  resulting  BRLCAD  model  looks  like  a  reasonable  object  (whatever  it  is). 

Figures  10  through  13  illustrate  original  BRLCAD  models  that  have  been  converted  to  the  IGES 
format  and  then  translated  back  to  BRLCAD  via  the  current  IGES  translator.  The  translation  to  IGES  was 
performed  by  a  rudimentary  translator  with  some  manual  file  editing.  For  practical  purposes,  the  tin 
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woodsman  model  shown  in  figure  10  translated  to  and  from  IGES  without  loss  of  precision  or  geometry. 
Some  nongeometry  information  was  lost  in  the  process,  such  as  object  names  and  material  properties. 
In  figure  12,  a  building  rests  on  a  mirrored  surface,  but  that  same  building  after  translation  to  IGES  and 
back  rests  on  a  geometrically  equivalent  surface  that  does  not  possess  the  mirror  property.  Object  colors 
are  translated  by  using  a  field  in  the  object  directory  entry.  This  color  field  may  contain  either  a  color  index 
referring  to  a  predefined  set  of  colors  or  a  pointer  to  a  color  definition  entity.  The  color  definition  entity 
allows  colors  to  be  specified  by  a  three-tuple  indicating  red,  green,  and  blue  intensities  similar  to  that  used 
in  BRLCAD.  so  the  object  color  gets  translated  exactly.  The  current  translator  does  not  handle  material 
properties  or  object  names,  although  there  are  IGES  entities  available  to  support  both  these  items. 

IGES  4.0  also  includes  the  capability  to  exchange  a  variety  of  three-dimensional  surfaces.  The 
BRLCAD  translator  takes  advantage  of  this  capability  in  a  limited  way  by  converting  Non-Uniform  Rational 
B-spline  surfaces  (NURBS)  to  a  BRLCAD  spline  solid.  Since  there  is  no  topology  present  for  BREP  models 
in  IGES  4.0,  there  is  no  way  to  infer  how  to  combine  the  NURBS  to  produce  solids.  This  translator  makes 
the  assumption  that  all  the  NURBS  in  the  IGES  file  are  part  of  a  single  solid.  This  may  not  always  be  a 
correct  assumption,  but  it  at  least  provides  a  minimal  translation  capability  for  CAD  systems  that  produce 
NURBS  and  NURB-surfaced  solids.  This  feature  is  not  intended  to  be  a  true  BREP  translator  and  will  likely 
be  replaced  in  future  releases  with  a  more  rigorous  approach. 

This  translator  is  distributed  as  part  of  the  BRLCAD  package  and  may  be  obtained  by  contacting 
the  Survivability/Vulnerability  Information  Analysis  Center  (SURVIAC)  at: 

SURVIAC  Aberdeen  Satellite  Office 

1003  Old  Philadelphia  Road,  Suite  103 

Aberdeen,  MD  21001  USA 

or  by  electronic  mail  to  <cad-dist@bri.mil>. 

6.  FUTURE  PLANS 

The  current  translator  has  limitations,  as  pointed  out  in  the  previous  sectior .  and  is  based  on  the 
current  ANSI  standard.  We  propose  to  continue  work  on  the  IGES-to-BRLCAD  translator  to  eliminate  the 
shortcomings  discussed  above  and  to  extend  its  capabilities  to  include  the  latest  IGES  release  (IGES  5.1). 
This  would  allow  BRLCAD  users  to  import  solid  models  from  virtually  any  CAD  system  that  supports  the 
IGES  solid  model  transfer.  The  advantage  of  such  a  capability  should  be  obvious:  when  solid  models  of 
military  systems  are  available  in  a  contractor's  IGES-capable  CAD  system,  it  would  virtually  eliminate  the 
duplication  of  effort  now  required  to  model  that  system  in  BRLCAD  for  vulnerability  studies.  Furthermore, 
such  a  capability  would  be  in  concert  with  the  Department  of  Defense’s  Computer-aided  Acquisition  and 
Logistics  Support  (CALS)  initiative. 
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We  believe  that  the  two  IQES  CSQ  solids  that  are  approximated  by  the  translator  can  be  more 
accurately  represented  by  either  improving  the  approximation  methods  or  by  implementing  and  supporting 
a  solid  of  revolution  and  a  solid  of  linear  extrusion  into  BRLCAD.  The  introduction  of  these  solids  as  full- 
fledged  BRLCAD  primitives  would  eliminate  any  need  for  approximation.  Short  of  adding  new  solids, 
improvements  to  these  approximations  are  possible.  For  example,  a  circular  arc  in  a  solid  of  revolution  can 
be  accurately  modeled  by  a  portion  of  a  torus,  or  an  elliptical  section  of  curve  in  a  solid  of  linear  extrusion 
can  be  modeled  as  a  section  of  a  BRLCAD  gentgc.  These  types  of  improvements  require  considerable 
programming  and  cannot  completely  eliminate  the  need  for  a  last  resort  approximation  similar  to  the  current 
method.  However,  because  both  of  these  solid  types  are  based  on  two-dimensional  curves  and  have 
simple  generation  schemes,  they  are  both  candidates  for  the  application  of  the  BRLCAD  spline  solid.  To 
apply  a  spline  approach,  each  section  of  the  defining  curve  would  be  converted  to  a  spline  curve  of 
appropriate  order.  Then  the  curves  would  be  used  to  generate  BRLCAD  spline  surfaces,  which,  when 
combined  into  a  single  BRLCAD  spline  solid,  would  create  an  extremely  accurate  model  of  the  intended 
solid. 


We  hope  to  begin  development  of  a  BRLCAD-to-IGES  translator.  Development  of  a  complete  IGES 
translator  package  would  position  BRLCAD  for  easy  introduction  into  any  established  CAD  oriented  work 
place.  The  capability  to  transfer  designs  back  and  forth  between  a  designer’s  commercial  CAD  systems 
and  BRLCAD  would  allow  him  access  to  BRLCAD  s  applications  codes  without  disrupting  his  normal  design 
process.  This  would  also  allow  the  designer  to  quickly  and  easily  prepare  a  BRLCAD  model  of  his  design 
for  submission  in  response  to  an  Army  Request  for  Proposals  (RFP)  or  Source  Selection  Evaluation  Board 
(SSEB),  resulting  in  a  cost  saving  for  foe  Army.  Such  submissions  have  been  required  of  Army  materiel 
providers  in  the  past  and  will  likely  continue  to  be  required. 

There  are  two  inherent  difficulties  in  developing  a  BRLCAD-to-IGES  translator.  First,  BRLCAD  has 
very  flexible  definitions  for  its  primitive  solids,  allowing  a  wide  range  of  possible  shapes  for  foe  gentgc  and 
the  genarb8  solids,  for  example.  The  IGES  entities  include  special  cases  of  these  BRLCAD  solids,  but  are 
not  general  enough  to  handle  all  cases.  One  approach  to  overcoming  this  problem  is  to  persuade  the 
IGES  community  to  modify  foe  IGES  specification.  The  mechanism  for  accomplishing  just  that  starts  with 
a  cooperative  development  and  use  of  proposed,  new  IGES  entities  by  two  or  more  independent 
organizations.  After  a  demonstrated  implementation  and  exchange  of  data,  foe  proposed  entities  may  then 
be  submitted  to  foe  IGES  committee  for  review  with  foe  intent  of  inclusion  in  the  specification  (ultimately, 
inclusion  in  the  ANSI  standard).  Another  possible  approach,  which  does  not  require  modifying  foe 
specification,  is  to  convert  each  unsupported  (by  IGES)  BRLCAD  CSG  primitive  into  a  BREP  object.  This 
approach  also  appears  to  be  a  viable  solution,  but  actually  leads  us  to  the  second  difficulty. 
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BRLCAD  is,  for  all  practical  purposes,  a  hybrid  CAD  system.  Although  BRLCAD  primarily  acts  as 
a  CSG  system,  it  allows  BREP  objects  to  be  intermingled  among  the  CSG  primitives.  The  IGES 
specification  maintains  a  definite  separation  between  CSG  and  BREP  systems  and  does  not  allow  the  two 
to  mix.  The  distinction  is  drawn  in  the  definition  of  the  IGES  boolean  tree,  allowing  only  CSG  primitives, 
solid  instances,  and  other  boolean  trees  as  operands.  No  BREP  entities  may  occur  in  an  IGES  boolean 
tree.  Again,  there  are  two  possible  solutions  to  the  general  incompatibility  of  BRLCAD  trees  containing 
BREPs  and  the  IGES  trees  that  cannot  contain  BREPS.  Since  IGES  does  not  allow  a  mingling  of  CSG 
and  BREP  objects,  one  solution  is  to  convert  all  the  BRLCAD  objects  to  BREP  objects  prior  to  translation. 
This  may  be  possible  in  the  near  future  as  the  BRLCAD  NMG  technology  is  perfected.  In  the  near  term, 
software  can  be  written  to  tesselate  all  BRLCAD  objects  to  form  a  type  of  BREP  object  with  all  flat,  faceted 
faces.  This  approach  will  solve  the  problem,  but  the  entire  model  would  then  be  reduced  to 
approximations.  However,  the  reader  should  be  aware  that  many  CAD  systems  reduce  their  objects  to 
faceted  BREPs  as  the  final  form  and  usually  permit  the  level  of  approximation  (such  as  approximating  a 
circle  by  a  series  of  straight  line  segments)  to  be  set  by  the  user.  Therefore,  one  can  argue  that  although 
the  resulting  approximations  might  not  be  rigorously  correct  from  a  perfectionist's  point  of  view,  the  faceted 
BREPs  are  usually  acceptable  for  most  applications— except  for  some  signature  applications.  Eventually, 
the  NMG  objects  are  expected  to  be  capable  of  supporting  nonplanar  surfaces  such  as  spline  surfaces; 
thus,  more  accurate  versions  of  CSG  objects  could  be  constructed  using  the  NMG  solid.  Even  so,  the 
conversion  of  the  BRLCAD  model  to  all  NMG  objects  for  the  purpose  of  translation  to  IGES  BREP  will 
cause  the  loss  of  the  original  architecture  of  the  model  because  only  the  BREP  counterpart  to  the  boolean 
tree — not  the  boolean  tree  itself— will  be  translated.  Also,  translation  of  the  IGES  BREP  (formerly  NMG) 
back  to  BRLCAD  will  not  produce  a  model  that  is  as  easily  edited  and  modified  as  the  original  boolean  tree 
form  of  the  CSG  model.  For  example,  a  simple  object  that  has  a  hole  through  it  (in  boolean  tree  form)  is 
easily  edited  to  change  the  size  of  the  hole.  However,  the  same  object,  after  conversion  to  BREP  and 
translation  to/from  IGES,  presents  some  challenge  to  modify  the  surfaces  that  define  the  object’s  hole  if 
the  user  requires  the  hole’s  size  to  be  changed.  But  it  should  be  noted  that  such  a  scenario  would  only 
occur  if  a  BRLCAD  model  must  be  handed  off  to  another  CAD  system  and  modified,  then  for  some  reason 
had  to  be  translated  back  into  BRLCAD.  However  one  could  make  the  assumption  that  once  received  from 
the  other  CAD  system,  the  existing  object(s)  need  no  further  modification;  thus,  the  loss  of  the  boolean  tree 
in  the  process  is  not  a  significant  shortcoming. 

The  second  approach  to  this  problem  is,  again,  to  influence  the  specification  itself.  Here,  a  small 
modification  of  just  the  IGES  definition  of  the  boolean  tree  would  allow  the  faithful  representation  of  any 
BRLCAD  object  in  an  IGES  file.  The  complete  and  unaltered  structure  of  a  BRLCAD  model  could  be 
preserved  through  translation  to  IGES  and  back  to  BRLCAD  if  the  IGES  boolean  tree  allowed  BREP  objects 
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as  operands.  This  is  clearly  the  optimal  approach  and  one  that  the  authors  support. 

7.  RECOMMENDATIONS 

BRLCAO  should  be  made  a  useful  tool  for  every  CAD  user — not  just  Army  or  Department  of 
Defense  users — by  developing  a  complete  IGES  compatibility  package.  This  package  should  extend 
beyond  the  solid  modeling  concerns  presented  in  this  report  to  include  the  generation  of  IGES  files  for  any 
line  drawing  outputs  BRLCAD  may  produce,  such  as  rthide  plots  or  mged  plots.  This  complete  package 
will  enhance  the  usability  and  acceptability  of  BRLCAD  throughout  the  CAD  world. 

The  U.S.  Army,  and  BRLCAD  in  particular,  should  be  represented  at  meetings  where  IGES 
specifications  and  product  data  exchange  standards  are  discussed  and  developed.  Such  representation 
has  the  potential  to  eliminate  some  of  the  difficulties  of  IGES  translation  for  BRLCAD  and  may  avoid  future 
problems  arising  from  decisions  similar  to  those  made  in  the  past  by  the  IGES  committee  (the  separation 
of  CSG  and  BREP,  and  the  limited  cases  of  certain  CSG  primitive  solids).  Private  industry  is  heavily 
represented  at  these  meetings,  and  without  some  demonstration  of  interest  and  influence  by  BRLCAD 
users/developers,  all  decisions  made  by  the  committee  will  be  in  the  best  interests  of  the  attendees, 
regardless  of  the  consequences  they  may  hold  for  BRLCAD. 

As  IGES  is  developing  to  maturity,  another  candidate  for  product  data  exchange  is  still  in  its 
infancy.  Product  Data  Exchange  Using  STEP  (PDES)  is  a  more  comprehensive  approach  under 
development  by  an  international  organization  (which  includes  the  IGES  committee  as  one  part).  The  STEP 
portion  of  the  PDES  acronym  represents  the  Standard  for  the  Exchange  of  Product  Model  Data,  which  is 
the  actual  candidate  for  an  international  standard,  while  PDES  is  the  U.S.  effort  supporting  STEP.  A 
satisfactory  discussion  of  PDES  is  beyond  the  scope  of  this  report,  but  the  reader  should  be  aware  that 
PDES's  potential  use  is  considerably  more  than  a  mere  replacement  of  IGES.  PDES  encompasses  an 
order  of  magnitude  greater  scope  and  application  than  IGES.  Whereas  IGES  is  concerned  with  the  product 
definition  of  an  object  (part,  component,  system),  PDES's  objective  is  to  address  the  complete  range  of  an 
object's  product  data  (i.e.,  data  relevant  to  the  product’s  complete  life  cycle).  As  an  analogy,  comparing 
IGES  to  PDES  is  like  comparing  nroff  to  the  UNIX  operating  system  in  terms  of  total  scope  and 
functionality. 

Work  on  PDES  dates  back  to  the  mid-1980s,  but  PDES  has  not  demonstrated  a  capability  that 
compares  to  IGES's  capability  when  IGES  was  a  little  more  than  a  half-decade  old.  That  statement  is  not 
a  criticism  of  PDES,  but  merely  accentuates  the  enormous  task  that  is  the  PDES  effort.  It  is  predicted  that 
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possibly  in  ten  years,  PDES  will  be  the  method  of  choice  for  exchanging  product  definition  data,  including 
solid  models.  If  PDES  is  eventually  accepted  as  a  standard  by  the  International  Standards  Organization 
(ISO),  then  it  is  definitely  in  the  best  interests  of  the  ARL  to  be  actively  participating  in  the  development  of 
this  new  specification.  Many  of  the  same  people  who  developed  IGES  are  heavily  involved  in  PDES,  and 
the  ARL  should  be  involved  to  insure  that  the  development  of  specifications  do  not  exclude  capabilities 
demonstrated  by  BRLCAD. 
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